this XSD schema is not the XSD schema of the FrameworkBundle config. It is the XSD schema of the DI component (not the same XML namespace)

http://symfony.com/schema/dic/services is the DI component, isn't it?

https://github.com/symfony/FrameworkBundle/blob/master/Resources/config/schema/symfony-1.0.xsd is in http://symfony.com/schema/dic/symfony/symfony-1.0.xsd

ah right sorry

Is it a good idea to link to the schema file on symfony.com since we may have different versions of it in the branches on GitHub but only one version on symfony.com?

The schema is not retrieved by requesting the url. Symfony's Xml parser replaces the configured extension namespace with the file path returned from getXsdValidationBasePath().

The FrameworkExtension looks like:

class FrameworkExtension // ...
{
    // ...
    /** 
     * Returns the base path for the XSD files. 
     * 
     * @return string The XSD base path 
     */ 
    public function getXsdValidationBasePath() 
    { 
        return __DIR__.'/../Resources/config/schema'; 
    }. 

    public function getNamespace() 
    { 
        return 'http://symfony.com/schema/dic/symfony'; 
    } 
}

So http://symfony.com/schema/dic/symfony/symfony-1.0.xsd becomes path/to/FrameworkBundle/Resources/config/schema/symfony-1.0.xsd which is the right schema in the right version

I know how the DependencyInjection handles schemas defined by a bundle. I was just referring to your tip. People might think that they can lookup the actual schema file under this url and that may confuse them.

I would use a complete valid XML file here.

What's the point of that?

With complete I mean adding the "header". This way, you can copy the example without having to investigate the proper namespace and schema definition and so on.

btw, this is broken. The closing tag should be </framework:config>

and this is broken in all XML snippets

Looking at Travis, this needs to get its own label to not be confused with fragments.path.